As a transaction concurrent execution control method of relational database, the concurrent execution control based on a pessimistic lock (an exclusive control mechanism) is known. In the concurrent execution control based on a pessimistic lock, a transaction TX1 locks all records to be referred to and updated beforehand, while another transaction TX2 to be concurrently executed stands by until the lock is released. By virtue of this, the transaction TX1 can ensure the atomicity (whether the whole transaction fails or succeeds).
However, if a pessimistic lock is used in a WEB system accessed for reference by a large number of users for example, then delay in user response may arise from the standby state, deadlock state, protocol overhead, and the like. Therefore, WEB systems which adopt the transaction concurrent execution control based on an optimistic lock are increasing in recent years.
In an optimistic lock (CAS: Compare And Swap), for example, an application acquires a record R1 to be updated and its version number R1_V1 from a perpetuation device (storage) before starting the transaction TX1. Further, the application updates the record R1 on a process memory, and increments the version number to R1_V2. Then, the application writes the updated record R1 and the version number R1_V2 into the storage. The storage compares (Compare) the “inputted version number R1_V2” with the “version number of record R1”. If the version number of record R1 remains the same as R1_V1, then it writes (Swap) the record R1 and the version number R1_V2 into itself, whereby the commitment succeeds. Otherwise, the other transaction TX2 aborts after determining that the record R1 is updated, whereby the commitment fails.
Because the optimistic lock does not need any lock mechanism and transaction management mechanism (TP monitors and the like), there is a merit that the transaction concurrent execution control system becomes a simple implement. Further, because a commitment success or failure is determined at the time of finally writing the record and the like into the perpetuation device, a plurality of transactions can concurrently access the same record for reference, thereby greatly improving the processing throughput of a user reference request in WEB systems.
The following Nonpatent Document 1 discloses an example of the transaction concurrent execution control system using an optimistic lock. The transaction concurrent execution system Voldemort disclosed in the Nonpatent Document 1 uses a Berkley DB as the storage. The Vodermort updates a data in its own memory space after acquiring the data to be updated inside of the transaction received from a client application, and the version number of the data. Then, at the time of writing the updated data into the Berkley DB, it determines whether or not the version number of the update data matches the acquired version number. If they are matched, then it writes, into the Berkley DB, the update data with a new version number having incremented the acquired version number. It is regarded as a commitment success when the writing is completed. If the version numbers are not matched, then it is regarded as a commitment failure.
[Nonpatent Document 1] “Project Voldemort”, <http://project-voldemort.com/>, 2011 May 31
However, in the concurrent execution control system of Nonpatent Document 1, if the number of concurrently executed transactions increases, then there is a problem of wasting the machine resource. The reason is that a transaction does not know whether or not the commitment of another concurrently executed transaction succeeds, and thus the former transaction consumes the machine resource until its own commitment fails.